- a [[technique]]
	- for [[hazard analysis]]
	- by [[nancy leveson]] and [[john thomas]]
	- [[pull]] [[stpa handbook]] [[stpa workshop]]
	- [[push]] [[stpa]]
		- i love how STPA defers key steps to a later stage so they can be done systemically, once partial but complete initial modeling has taken place.
		- it can be applied recursively. it could be argued that because STPA can be applied recursively the cost of abstraction is minimized or at least bound.
	- 4 [[steps]]
		- 1. define the purpose of the analysis, including [[losses]], [[scope]], [[hazards]], [[constraints]] (optionally derived also from [[sub hazards]]).
		- 2. model the control structure
		- 3. identify unsafe control actions
		- 4. identify loss scenarios
	- step one: [[define the purpose of the analysis]]
		- start with the [[losses]], which involve something of value to stakeholders
		- continue by defining the [[scope]] of the system
		- find [[hazards]], which are systemic states or conditions to be prevented, and which together with (worst-case) environmental conditions lead to [[losses]].
			- [[hazards]] + [[environmental conditions]] -> [[losses]]
		- find [[system level constraints]]. 
			- they can look like [[hazards]], inverted.
			- or define how the system must [[minimize losses]] in case the hazards occur.
		- optionally find [[sub hazards]], which might also help define further constraints
	- step two: [[model the control structure]]
		- ![[Pasted image 20210718234132.png]]
		- a control structure is a system model that is composed of feedback control loops.
			- a good control structure will enforce the system level constraints.
		- control goes down, feedback goes up
			- vertical axis represents a hierarchy ([[heterarchy]]? perhaps in voting systems)
		- [[responsibilities]] can be assigned to each control structure entity; they are refinements of [[system level constraints]]
		- [[feedback]] can be derived from [[responsibilities]] (which information does the process model need to contain?)
	- step three: [[identify unsafe control actions]]
		- an [[unsafe control action]] is one that, in a particular context, will lead to a [[hazard]].
		- it must include the actual (real) context in which the control action is unsafe, instead of controller beliefs; and it must be linked to a hazard.
		- define [[controller constraints]]: behaviours that need to be satisfied to prevent UCAs. they can usually be derived from negations of the UCAs.
	- step four: [[identify loss scenarios]]
		- a [[loss scenario]] describes the [[causal factors]] that can lead to the [[unsafe control actions]] and to [[hazards]].
		- 4a: write scenarios which cause UCAs
		- 4b: write scenarios where control actions are ont followed